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ACCESSING A HIERARCHICAL DATA STORE THROUGH AN SQL INPUT 
Cross-reference to Related Applications 

The present application claims benefit of the filing date of U.S. Provisional 
5 Application No. 60/1 04,682 entitled MODELING TOOL SYSTEMS AND 

METHODS, filed on October 16, 1998, incorporated by reference herein in its entirety. 

The present application is related to a co-pending U.S. Patent Application No. 

(Atty. Docket #22074661-25535) entitled APPARATUS AND METHOD FOR 

MODELING TOOLS, being concurrently filed on the same day, which is incorporated 
10 by reference herein in its entirety. 

The present application is related to a co-pending U.S. Patent Application No. 

(Attorney Docket #22074661-25532) entitled METHOD FOR IMPACT 

ANALYSIS OF A MODEL, being concurrently filed on the same day, which is 
incorporated by reference herein in its entirety. 
15 The present application is related to co-pending U.S. Patent Application No. 

(Attorney Docket #22074661-25531) entitled METHOD FOR DETERMINING 

DIFFERENCES BETWEEN TWO OR MORE MODELS, being concurrently filed on 
the same day, which is incorporated by reference herein in its entirety. 

The present application is related to co-pending U.S. Patent Application No. 

20 (Attorney Docket #22074661-25533) entitled METHOD AND SYSTEM FOR 

AN EXTENSIBLE MACRO LANGUAGE, being concurrently filed on the same day, 
which is incorporated by reference herein in its entirety. 

Field of the Invention 

The present invention relates to a database management system, and in 
25 particular to an Application Programming Interface (API) that allows application 
programs access to various database management systems. 

Background Information 

Open DataBase Connectivity (ODBC) is an Application Programming Interface 
(API) that provides a common interface for accessing various structure query language 
30 (SQL) based database management systems. Most vendors have added an ODBC 
interface to their relational databases. One major disadvantage of the conventional 
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ODBC is that it was designed to access relational database management systems that 
use standard SQL language in their queries and its use outside the relational databases 
has met with significant problems because SQL assumes the relational nature of the 
database. 

5 Therefore it is desirable to provide a system and method for providing an ODBC 

interface or driver that allow access to non-relational data store such as a hierarchical 
obj ect/property model. 

Summary of the Invention 

The present invention provides a driver that allows access of data stored in a 
10 hierarchical data store through an SQL input query. Based on the SQL input, the driver 
transforms a hierarchical data store into relational database tables. Preferably, the tables 
hold pointers that point to the actual data stored in the hierarchical data store. Then the 
SQL input is executed using the transformed tables. 
Brief Description of the Drawings 
15 Figure 1 is a block diagram showing an ODBC driver interfaced between an 

SQL report generator and a hierarchical data store according to the present invention. 
Figure 2 is a flow chart of the ODBC driver according to the present invention. 
Figure 3 illustrates a representation of a hierarchical data store and that of an 
equivalent relational database. 
20 Detailed Description of the Invention 

An hierarchical data store is represented as a graph of objects and properties. 
Objects may be owned by and conceptually aggregated into other objects. Objects may 
hold references to other objects via reference properties. Properties are owned by and 
aggregated into objects. FIG. 3 includes a representation of such an hierarchical data 
25 store and that of an equivalent relational database. 

The hierarchical data store in FIG. 3 is a model of customers and their order 
information. The data store includes an object or a group of objects called "Customer" 
each having a unique internal identification number, "intid". The "Customer" object 
has three properties: one scalar property and two vector properties. The one scalar 
30 property is of type ''Name" which can hold only one value by definition. The first 

vector property is of type "Phone_number" which may hold many values by definition. 
The second vector property is of type "Order ref ' which may also hold many values. 
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Each value of "Order_ref 9 is a pointer which references another object called "Order". 
The "Order" object has a property of type "DateOrdefed" which stores the date of a 
particular order that has been placed. The equivalent data store in a relational database 
can be represented as three separate tables as shown on the right side of FIG. 3. A 
5 "Customer" table has two columns named "Id" and "Name", an "Order" table has three 
columns named "Order_id", "DateOrdered" and "Cust", and a "Phone" table has three 
columns named "Cust", "Seq" and "Phonenumber". The three tables are linked to 
each other through "Id" of Customer, "Cust" of Phone and "Cust" of Order which have 
identical values. 

10 FIG. 1 is a block diagram showing an ODBC driver 6 interfaced between an 

SQL report generator 2 and a hierarchical data store 4. As discussed above, a 
conventional ODBC is designed to access relational databases using standard SQL 
language queries. The ODBC driver 6 of the present invention allows standard SQL 
language queries from an SQL report generator 2 to be used against a standard 

15 object/property model of information such as a hierarchical data store 4 according to the 
steps of FIG. 2. In step 10, the driver 6 receives the SQL input from the generator 2. In 
step 12, the driver 6 identifies object classes and their properties to be processed based 
on the received SQL input. In step 14, the hierarchical data store 4 is transformed into 
relational database tables with various columns such that the hierarchical data store 4 

20 appears to be a relational database to the SQL report generator 2. In a preferred 

embodiment, step 14 involves the following manipulations such that the hierarchically 
stored database is transformed into relational database tables: 

1 . each class of object is transformed into a table. Each table of this type has 
two pseudocolumns: an "Id" that contains the unique identifier of the instance and is the 

25 primary key, and an "Owner" that contains a foreign key reference back to the owning 
object; 

2. each non-reference scalar property of an object becomes a column in the 
object's class table; and 

3. each non-reference vector property is transformed into a table. Each table of 
30 this type has two pseudocolumns: a "Sequence" column that contains a sequence value 

for each element of the vector and is part of the primary key for the table, and an 
"Owner" column that contains a foreign key back to the owning object and is part of the 
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primary key; and 

4. each reference property, both scalar and vector, may be used to calculate a 
foreign key relationship from the referenced object to the object owning the reference 
property. 

5 When the necessary tables and columns are created/transformed, they preferably 

have pointers that point to the actual data residing in the hierarchical data store, and do 
not store the data themselves. The query contained in the SQL input is then executed in 
step 16 on the transformed tables. In step 18, the result of the execution is then passed 
to the report generator 2 that transmitted the SQL input. 
10 A more detailed explanation of the steps in FIG. 2 will be provided below with 

reference to a couple of example SQL inputs. As one example, assume that the ODBC 
driver 6 receives the following SQL input query transmitted from the SQL report 

generator 2: 

Select DateOrdered from Order a, Customer b where a.Cust = 

1 5 b.Id and b.Name = "Doe". 

The above SQL input means that the generator would like to receive 
DateOrdered for all orders that "Doe" has placed. In relational terms, the way the 
Customer and the Order tables are connected or joined is that the value in the "Cust" 
column of the Order table should match the value in the Id column of the Customer 

20 table. The "Id" is the primary key for the Customer table and "Cust" is a foreign key of 
the Order table. As can be appreciated by persons of ordinary skill in the art, the 
hierarchical data store in FIG. 3 is not set up in a form that is readily usable by a 
conventional ODBC interface. This is one of the problems that is solved by the ODBC 
driver 6 according to the present invention. 

25 The ODBC driver 6 analyzes the received SQL input and identifies the 

object classes that need to be processed. The ODBC driver 6 then transforms each 
object class into a table. In other words, a database table is created for each identified 
object class because object classes map to tables. In the example above, there are only 
two objects, "Customer" and "Order". Accordingly, two tables named "Customer" and 

30 "Order" are created. As part of the transformation process, the columns for the tables 
are created partly by analyzing what columns are being referenced in the received SQL 
language and by analyzing the properties of the object classes since columns map to the 
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5 

properties. In addition, the internal identification number "intid" is mapped to a 
column of the corresponding table. As a result of the transform, the ODBC driver 
creates a "Customer" table with "Id" and "Name" columns, and an "Order" table with 
"Order Jd", "DateOrdered" and "Cust" columns as shown in FIG. 3. The "int_ id" and 
5 "Name" of the Customer object map to "Id" and "Name" columns of the "Customer" 
table, and the "int_ id" and "DateOrdered" of the Order object map to "Orderjd", 
"DateOrdered" columns of the "Order" table. 

At this point, the only column that we need to synthesize is the "Cust" 
column of the Order table. However, the customer property in the hierarchical data 

10 store does not exist in the "Order" object. In other words, there's no property in the 
Order object pointing back to the "Cust" ("int_id") of the Customer object. In fact, it's 
the inverse of the relational database because it's the Customer object that points to the 
Order object. This is a difference in the topologies between a relational database and an 
object/property model such as the hierarchical data store. 

15 In this case, it is recognized that the "Cust" column is a foreign key in 

the relational database. The foreign key concept is similar to a reference property in the 
hierarchical data store such as the "Orderref" property of the "Customer" object 
Recognizing that the query requires a foreign key backwards, the "Order ref ' property 
of the "Customer" object is read, the inverse relationship is synthesized, and the "Cust" 

20 column is then synthesized or created using the "intid" of the Customer object. 

With the necessary tables and columns fully built, the tables preferably 
store pointers that point to the actual data residing in the hierarchical data store, and do 
not store the data themselves. Alternatively, actual data may be stored in the tables. 

In a second example of an SQL language input, assume that the ODBC 

25 driver 6 receives the following: 

Select phone_number from Customer a, Phone b where a.Id = b.Cust and 
a.Name = "Sears". 

In this example, a different transform occurs because it references a 
vector property "phone_number". As discussed above, each non-reference vector 

30 property is transformed into a table. The property itself maps to one column named 
"phone jiumber". Two more columns are synthesized. One column named "Cust" is 
the id ("int_id") of the object ("Customer") that owned the "phone_number" and a 
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6 

second column named "seq" is an arbitrary increasing number so that different phone 
numbers for the same object can be differentiated. 

As in the first example, once the necessary tables and columns are fully 
built, the tables preferably store pointers that point to the actual data residing in the 
5 hierarchical data store. The SQL input is then executed using the transformed tables. 
The data matching the selection criteria of the SQL input are selected from the 
hierarchical data store pointed to by the pointers stored in the transformed tables and 
passed to the report generator 2. Again, actual data may be stored in the tables. 

From the foregoing, it will be appreciated that, although specific 
1 0 embodiments of the invention have been described herein for purposes of illustration, 
various modifications may be made without deviating from the spirit and scope of the 
invention. 
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7 

What is claimed is: 

1 . A method of accessing data stored in a hierarchical data store by using 
an SQL input, comprising the steps of: 
receiving an SQL input; 

transforming a hierarchical data store into relational database tables 
based on the received SQL input; and 

executing the SQL input using the transformed tables. 
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